Subject: COS Tables for Subnetworks with Priority

From: "J. G. Dudley (444/4358)" <[email-masked]>
Date: Thu, 6 Jul 95 15:27:09 EDT

I have some comments on the subject raised by Jim Cobban and Dave
Finnie.

When trying to distinguish for route selection between the different
types of virtual circuits available on a subnet, my preference is
to assign TG characteristics to each VC type based on its real
characteristics.  In the example Jim cites, two VCs are established
across a subnet with the same parameters except that one VC has a
higher priority than the other.  It is reasonable to assign a higher
propagation delay to the lower priority VC because its traffic will
experience significantly more delay when the network is loaded.
Likewise, it is reasonable to assign a higher cost to the higher
priority VC.  One would expect a public network provider to have a
higher tariff for the higher priority service; else, a consumer has
no motivation to select a lower priority service.  Even when the subnet
is private with no tariffs, there is cost associated with the higher
priority VC in that its use reduces the performance of other VCs
across the subnet.

The current default batch COS tables prefer "free" TGs and ignore
propagation delay; therefore, a batch COS table (the current default
table either used as is or with minor realistic modification) would
prefer the lower priority VC.  The current default interactive COS tables
are willing to accept some cost in order to prevent the propagation
delay from rising too high or the effective capacity from falling too
low; as a result, it is possible (again, with minor realistic
modification to the default table) to construct an interactive COS table
that would prefer the higher priority VC.  Modifications to the default
COS tables that reflect the customer's routing preferences should
not have a drastic effect on routing in portions of the network with no
subnets providing priority service.

This approach depends on there being real differences in the service
classes provided by the network in order to exploit the power of
COS-based route selection.  As a result, similar techniques can be used
for ATM subnets with different QoS classes.  However, this approach
does not provide a mechanism to segregate batch and interactive traffic
onto separate VCs with identical characteristics; such function would
require the technique using rows with mutually exclusive characteristics
Jim outlined.

Gary Dudley
IBM APPN Architecture Team

---

From: Dave Finnie <[email-masked]>
Date: Fri, 7 Jul 1995 08:38:36 +1000

Gary,

You've raised some good points. I am a little confused about use of
cost as you've described. Surely, according to the way you have
described it, *all* private lines have a cost. Cable costs money,
hardware support, bridges, etc, cost money. If a line is used heavily
and becomes congested, a new one may need to be installed, or the
equipment upgraded, etc.

Therefore, it would seem that all TGs have some cost associated, which
is clearly not the intention of the architecture. As far as I am
aware, cost is intended to reflect external costs caused by use of the
TGs (by time or traffic volume).

So again, it seems, we need to "fiddle" with the definitions to
achieve Jim's aim. More importantly, this fiddling is totally out of
our hands. The customers may not have the expertise to understand the
issues, and I think all of us would do some long hard thinking before
we chose values for cost/propagation delay in this case, as we *know*
we could affect network performance.

Dave